Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

本篇是 建構安全軟體開發 系列文的 EP24。

安全 Interface (介面) 設計

在 Interface (介面) 的設計當中，可區分成給使用者操作的Interface 及給程式呼叫的 Interface。

Security Management Interface (SMI)

當提及 SMI 的概念時，就是要提到整體系統當中的最高權限並且能操控以下類似作業：

• 新增/修改/刪除使用者
• 設定不同權限給使用者角色
• 系統重啟
• 變更系統安全設定
• 存取稽核紀錄、使用者認證、例外日誌...等

針對這些 SMI 的設計，必須強化其控制設計，例如透過：

• 憑證驗證
• 不允許或盡可能限制遠端作業，或是必須經過安全通道連線(例如 VPN)。
• 強化角色授權並落實職責分離。
• 使用多因子驗證機制。
• 針對 SMI 等功能進行另外的稽核紀錄。

當然也可以考慮下列指引作為：

• 採取預設值安全設置。
  從過去的分析來看，絕大部分的使用者都只會使用到基本功能，所以可以設計應有的預設存取權限。
• 使用者醒目機制：
  例如在瀏覽器當中透過 SSL/TLS 連線時會有盾牌或鎖頭的圖示。
• 可撤銷先前授權機制：
  例如在使用 OAuth 驗證連線到第三方程式後，之後可將第三方程式的授權取消，禁止第三方程式使用該授權。
• 檔案存放安全管制措施：
  例如嚴格限制敏感資料的存放區(透過其安全管制措施)，若有其他可選擇的選項存放時，要特別暗示其不安全之問題觀點。
• 清除安全選項：
  例如在連續的安全提示後，確認使用無誤後，可選擇不再提示。

OOB-IOB-LOB 通道機制

Out-Of-Band：
透過獨立的通道(物理性)進行系統的資料與裝置維護管理，與一般使用通道分開。
In-Of-Band：
透過同樣的一般通道進行系統的資料與裝置的維護管理。
Lights-Of-Band：
是一種 OOB 的特殊形式，透過的驗證與安全保護方式再透過一般用通道進行系統的資料與裝置的維護管理。

舉例來說，如果一個設備的管理或使用通通透過相同的網路介面機制達成，則是 In-Of-Band；如果管理與使用透過分離的網路介面機制達成，則是 Out-Of-Band。

例如進入大賣場，顧客跟員工通道會分離(OOB)，但有些會再一起(IOB)，若雖然在一起但會透過驗證機制進入特殊管制區域(LOB)。

日誌介面

在軟體開發當中必然會有不同的環境應對開發、測試、營運模式，而其中的日誌紀錄會有不同的管理機制，並且要設計其不同層級的日誌機制。

傳輸通道設計選擇

現今網路傳輸的方式有相當多種，而具有安全設計的通道例如 IPSec(網路層)、SSL/TLS(應用層)、SSH(應用層) 都被設計用來保護裝置之間的資料安全性，在設計其系統運作時可先考量選擇這些業界加密標準通道，以確保資料的安全性。

再次考慮安全設計

Authentication (驗證/識別) 指引

• 使用多重因子驗證 (something that you know, have, are)
• 密碼的儲存必須經過雜湊處理
• 僅使用安全函式比對雜湊密碼
• 傳遞密碼只使用堅固的安全通道
• 提供泛用性的驗證錯誤警示

不良的驗證機制 (A02: Broken Authentication) 在 OWASP Top 10: 2017 當中排行第二：

在 CWE 的弱點列舉：

• CWE-287 Improper Authentication
• CWE-297 Improper Validation of Certificate with Host Mismatch
• CWE-384 Session Fixation

雖然在 OWASP Top 10: 2021 降至第七名 (A07:2021 – Identification and Authentication Failures)，但是其實在 CWE 的弱點列舉裡，有更多有關係的弱點存在：

• CWE-255 Credentials Management Errors
• CWE-259 Use of Hard-coded Password
• CWE-287 Improper Authentication
• CWE-288 Authentication Bypass Using an Alternate Path or Channel
• CWE-290 Authentication Bypass by Spoofing
• CWE-294 Authentication Bypass by Capture-replay
• CWE-295 Improper Certificate Validation
• CWE-297 Improper Validation of Certificate with Host Mismatch
• CWE-300 Channel Accessible by Non-Endpoint
• CWE-302 Authentication Bypass by Assumed-Immutable Data
• CWE-304 Missing Critical Step in Authentication
• CWE-306 Missing Authentication for Critical Function
• CWE-307 Improper Restriction of Excessive Authentication Attempts
• CWE-346 Origin Validation Error
• CWE-384 Session Fixation
• CWE-521 Weak Password Requirements
• CWE-613 Insufficient Session Expiration
• CWE-620 Unverified Password Change
• CWE-640 Weak Password Recovery Mechanism for Forgotten Password
• CWE-798 Use of Hard-coded Credentials
• CWE-940 Improper Verification of Source of a Communication Channel
• CWE-1216 Lockout Mechanism Errors

雖然看得出來是因為在 OWASP Top 10: 2021 的命名跟 2017 主題有點不盡相同，而導致 CWE 涵蓋的弱點更多了，但也不可避諱的是從 5 年多的時間內，仍有這麼多有關 "Authentication" 的問題，亟需好好的去重視。

而目前很常見 Single Sign-On (SSO) 的方式來在不同領域系統的進行身分驗證，而其中常透過以下方式進行驗證：

• SAML: Security Assertion Markup Language (by XML)
  可達成

  1. 識別：判定使用者為其所宣稱的使用者。
  2. 授權：將使用者授權傳送給應用程式以存取特定系統或內容。

• OAuth/OAuth2: Open Authorization(by Json)
  可達成
  授權：允許並授權當前的應用有限度的使用在原本識別後的資料。

• OpenID Connect
  補充 OAuth/OAuth2 的驗證身分的識別性不足，進而強化 OAuth/OAuth2 身分驗證的安全性。

在不同情境下，有其適合的驗證模式。SAML 常被用於網頁瀏覽不同領域網站時的 SSO；OAuth/OAuth2 與 OpenID Connect 常被整合運用於裝置、API 中的 SSO。

而目前微軟相關的身分識別平台有整理相當完整的文件可參考：

• SAML 的 SSO
• OAuth 2.0 授權流程
• OpenID Connect